-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(bazel): add MODULE.bazel files for bzlmod #1802
Conversation
✅ Deploy Preview for nifty-bassi-e26446 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
I'm trying to introduce bzlmod here but Package 'website/tools/pelican' is failing because of the use of entry_point. I'm seeing this : fail("""Please replace this instance of entry_point with the following:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
arggh - i wrote some feedback but it seems github stole it 8(
thanks for working on this
im not so familiar with bzlmod, so need to do a bit of testing
wondering if we lose the dep shas in this PR
I believe it would be better to start by updating rules_python and migrate from entry_point to py_console_script_binary and then migrate to bzlmod. WDYT ?
I don't it's a good idea. As Envoy is depending on toolshed it will need to migrate to bzlmod to use toolshed as a bazel_dep. |
sounds like a good idea - i think
not sure im following here |
Envoy depends on toolshed but still uses the old way of handling dependencies so you cannot remove the old way in toolshed until envoy uses bzlmod to use toolshed as a bazel_dep |
i got that bit - just wasnt understanding response to question about not having shasums |
You won't have any shasum, just the name of the dep and it's version with, something like that :
|
k - so trying to get up to speed here - does this mean sha resolution/evaluation is done in the lock file and end users no longer are expected to manually set these etc ? |
It means that they won't need to maintain the shasum themselves, everything is going to be handled in the BCR |
lmk when this is ready to land - excited to get started with this |
de6d4de
to
6f18157
Compare
Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
@phlax, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, with one question - thanks @mmorel-35
@@ -179,3 +179,6 @@ $RECYCLE.BIN/ | |||
|
|||
!gh-actions/**/dist | |||
!gh-actions/github/mutex/lib | |||
|
|||
# Bazel | |||
MODULE.bazel.lock |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the lockfile not checked in to repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it isn't useful to share it as it is plateform dependant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm - i thought the utilitiy was that it contains the hashes (ie ensures you are downloading exactly the same file/s)
i seem to remember a similar issue with python lockfiles (which are generally checked in)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if the docs says it's better to persist it. You'll see many BCR maintainers discouraging it's persistance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah the docs seem to suggest this should be checked in afaict (https://bazel.build/external/lockfile#merge-conflicts)
i think we will need to do this - we cant just ensure trust/reproducibility from just versions
Signed-off-by: Matthieu MOREL matthieu.morel35@gmail.com